feat(contexts): give applications a menu with its own API - #3135

Part of the stack on #3133. Implements the menu proposal on #3100: the model and the API. Export and import follow in #3138. This replaces the earlier version of this pull request, together with #3136 and #3137.

Size: 3322 lines: 909 code, 414 tests, 1991 generated OpenAPI and 8 version.

Agreed on #3100

• No technical name on menu items. An export refers to an item's group by its position in the exported menu.
• Three target columns (page_id, node_rel_id, url), of which at most one is set. The service enforces it; the rule is in the entity docblock.
• Remnants: deleting a target removes its menu items in the same transaction; creating or changing an item checks its target in its own transaction; reading still leaves out an item whose target is missing, as a safety net. No background job.
• Empty groups stay in the data. Editors see them, readers without manage access don't.
• The application id is contextId, like the other application routes, not context as in the proposal.

What changes

• A menu item opens at most one thing: a page of the application ({pageId}), a table or view of the application by its node relation ({nodeRelId}), or an http or https link ({url}). An item that opens nothing is a group. Groups are top-level and only groups hold items, so a menu is one level deep.
• An item without a title shows the title of what it opens: the page, the table or view, or the link. The start page without a title shows the name of the application. The API returns both title (as stored) and displayTitle.
• A new application gets one item, without a title, for its start page. It's an ordinary item. Applications that exist today have no items, and an application without items opens its start page, so there's no data migration.
• Cleanup: an item goes with its target, in the same transaction: when its page is deleted, when its table or view leaves the application (through the application's nodes, a scheme import, or because the table or view is deleted, also with its owner), and with the application. The items of a deleted group move to the top level.
• At most 200 items per application.
• The application response stays as it is on main. Permission checks and the application response don't load the menu.
• Endpoints on api/2, with #[ApiRoute]:
  • GET /api/2/menu?contextId={id} returns the menu as a flat list in display order, with parentId
  • POST /api/2/menu adds an item to the end: contextId, title, icon, description, target
  • PATCH /api/2/menu/{itemId} changes an item; a target replaces the previous one, a group that holds items can't get one
  • DELETE /api/2/menu/{itemId} deletes an item
  • PUT /api/2/menu/order takes contextId and items: [{id, parentId}] in display order. It lists every item exactly once, a parent is a top-level group listed before its items, and it saves all of it or nothing ("changed in between, reload"). It returns the whole menu.
• Permissions: reading needs read access, changes need manage access, checked once through the item's application. Outsiders and items of another application get a 404, readers who try a change a 403, a target outside the application a 400. #[RequirePermission] covers the endpoints with contextId; the item endpoints check through the item's application.
• Rate limits like pages, with #[UserRateLimit]: create 20 a minute, change and order 60 a minute.

How it was tested

On Nextcloud 34 with PostgreSQL:

• MenuServiceTest against the database: the start page item of a new application, title fallback for every kind of target, invalid items (data provider), at most one target, empty groups hidden from readers, the 200-item cap, PATCH semantics, a group with items can't get a target, order and grouping, deleting a group, invalid orders that save nothing (data provider), cleanup with the page, the node and the application, a dangling item left out, and only managers change the menu (data provider)
• MenuControllerTest: arguments passed on and every error mapped to its status (data providers)
• the full unit suite on PostgreSQL and SQLite: 601 tests
• composer cs:check, psalm and rector, all clean

🖼️ Screenshots

Backend only, no UI changes.

🏁 Checklist

• ⛑️ Tests (unit and/or integration) are included or not needed
• 🔙 Backport requests are created or not needed: /backport to stableX.X
• 📅 Milestone is set
• 🌸 PR title is meaningful (if it should be in the changelog: is it meaningful to users?)

🤖 AI (if applicable)

• The content of this PR was partly or fully generated using AI